[camera_android_camerax] Fix video recording after backgrounding app by camsim99 · Pull Request #12145 · flutter/packages

camsim99 · 2026-07-08T17:00:08Z

WIP towards fixing flutter/flutter#183880.

As of now, reviewers focus on issues implemenation_plan.md.

Normal pull request information above the line.

This pull request is an attempt to "oneshot" fixing flutter/flutter#183880. Using antigravity to execute a plan that is collaboratively worked on. The "rules" are to not allow human authored code to camera_android_camerax and to not rely on human code review feedback for code iteration.

We can add documentation, skills, mcp servers, presubmit test etc. Basically any "support infrastructure" for development is allowed but the package changes must be generated as a single pass.
When we discover that the plan is not good enough we will blow the package changes away and either modify the plan or add more support infrastructure and try again.

For more information see the working doc in go/flutter-project-one-shot

Pre-Review Checklist

If you need help, consider asking for advice on the #hackers-new channel on Discord.

Note: The Flutter team is currently trialing the use of Gemini Code Assist for GitHub. Comments from the gemini-code-assist bot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.

Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. ↩ ↩²

…e harness

camsim99 · 2026-07-08T17:05:33Z

+dart run ../../../script/tool/bin/flutter_plugin_tools.dart integration-test --android --packages=camera_android_camerax
+```
+
+### Manual Verification


In an ideal world, it would know how to launch the emulator and test but I actually don't know if the agent would have any way of interacting with the emulator after that in a meaningful way (even if it were a more minimal app than the example).

Could we do this via an espresso test?

That's a great idea! Yes, definitely.

Well wait a quick search makes it seem like we would need UiAutomator to get real camera recordings. We could mock it but I'll have to look into what that would look like.

Or we could use something like https://pub.dev/packages/flutter_mcp or https://github.com/leancodepl/marionette_mcp

camsim99 · 2026-07-08T17:32:30Z

+    });
+```
+
+## Verification Plan


In our first plan, we had it explicitly list out the steps it would take to make sure that the code is high quality. I'm ok with that not being explicitly included because it will be in our AGENTS.md and the skills, but just noting in case other reviewers do not agree.

for now I think the verification steps should be listed especially if there are no artifacts of that verification.

For a human, this would be something like, I ran it on a pixel device and swapped between front facing and rear facing camera and it the example app did not crash.

Somehow I missed this comment and will include in on the next iteration. But question: thoughts on the step just be to run the pre-push skill? Most of those steps are part of the skill (the only one not included is the gradle check which honestly would be a good addition).

camsim99 · 2026-07-08T17:37:25Z

+```
+
+### Manual Verification
+1. Run the example app (`example/lib/main.dart`) on an Android device.


At the very least it can run the example app and see if it builds (or at least try a flutter build apk).

camsim99 · 2026-07-08T18:17:17Z

This might not be the final AGENTS.md we use in the plugin, but included my draft for now in case some of the core information was useful for creating the implementation plan.

#12066 is my actual proposal.

stuartmorgan-g · 2026-07-08T19:12:20Z

+dart run ../../../script/tool/bin/flutter_plugin_tools.dart integration-test --android --packages=camera_android_camerax
+```
+
+### Manual Verification


Could we do this via an espresso test?

stuartmorgan-g · 2026-07-08T19:14:23Z

+dart run ../../../script/tool/bin/flutter_plugin_tools.dart integration-test --android --packages=camera_android_camerax
+```
+
+### Manual Verification


What does it mean for a one-shot plan to have a manual verification step? Does that mean that the reviewer is expected to read and carry out this section as part of the code review?

Yes. In both of our one-shot plan attempts, we did not ask for this section specifically, but I assume it's generated because the agent assumes it can't verify the solution itself. I do wonder if that's true, though. It can definitely launch an emulator and run the app, but I need to verify it could interact with it as we'd expect.

If it is expected to be done by the reviewer we should call the section "reviewer verification" and it should be required to be part of the pull request.

In my experience "manual verification" were steps that did not produce artifacts like automated tests that were done to ensure the code was correct and they were only done once near the end but not after all final edits.

reidbaker · 2026-07-13T20:26:27Z

+     await deviceOrientationManager.stopListeningForDeviceOrientationChange();
+    recording = null;
+    pendingRecording = null;
+    videoOutputPath = null;


Something in the code above stores the video safely when the camera is disposed. Instead of setting these values to null here can we make that code null out the recording?

For example if there is a lifecycle event from the camerax library for native recording stop can we forward that call instead of relying on the dispose? (maybe dispose is the call being forwarded?)

The agent addressed this on line 25. The explanation makes sense to me if I understand your question correctly because stopVideoRecording does what you're describing but we need this logic in dispose because this issue specifically pertains to the recording being stopped by force before an app can call stopVideoRecording.

reidbaker · 2026-07-13T20:27:49Z

+```
+
+#### [MODIFY] android_camera_camerax_test.dart
+Add assertions in the `dispose` test to ensure that the recording state variables are properly nullified when `dispose()` completes.


FWIW It feels like a pattern that information about camera is in a bunch of variables that need their state cleared. Is there a better pattern for this that we can use. Maybe a CameraState object that we can call dispose on that handles all its own variables and makes the lifecycle more clear.

I think this is a great suggestion, but I consider this out of scope for solving the video recording issue (I think it would be a medium to large scale change). Filed flutter/flutter#189599 so we keep that work on our radar.

reidbaker · 2026-07-13T20:28:26Z

+     verify(mockDeviceOrientationManager
+         .stopListeningForDeviceOrientationChange());
+
+    // Verify state is cleared


can this test also ensure that the video was saved correctly?

Ok it put this verification in the integration test (I might have put the comment there by accident...oops), so I can add this comment for the next iteration.

camsim99 added 2 commits July 8, 2026 09:46

add draft of AGENTS.md since something like this should be part of th…

8c98295

…e harness

Add first iteration of implementation plan

7874903

github-actions Bot added the p: camera label Jul 8, 2026

camsim99 commented Jul 8, 2026

View reviewed changes

Comment thread packages/camera/camera_android_camerax/implementation_plan.md

stuartmorgan-g reviewed Jul 8, 2026

View reviewed changes

Second iteration

8e6b053

reidbaker reviewed Jul 13, 2026

View reviewed changes

Third iteration

2fa34ae

camsim99 mentioned this pull request Jul 16, 2026

[camera_android_camerax] Refactor camera state fields into camera state object flutter/flutter#189599

Open

camsim99 requested a review from reidbaker July 16, 2026 17:53

Uh oh!

Conversation

camsim99 commented Jul 8, 2026

Pre-Review Checklist

Footnotes

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

reidbaker Jul 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

reidbaker Jul 13, 2026 •

edited

Loading